原帖 ｜ martin ｜ 2026-08-31 17:55 ｜ 👍0 ｜ 阅读约1
之前直播 43k的大佬想要成为年薪百万的 SE，然后有看到一本书是讲怎么做SE——《》
这本书由 INCOSE（International Council on Systems Engineering）组织编写，是系统工程领域比较系统的一本参考书，也想把最近读到的一些内容和大家分享一下。
1. 从全局视角理解 Systems Engineering
我觉得这本书比较有价值的一点，是它并不是只介绍某一个具体的工程方法，而是站在系统全生命周期的视角，去解释一个复杂系统应该如何从 stakeholder needs 和 requirements 出发，逐步形成系统架构，并最终走向实现、集成、验证和确认。
我举一个例子来说明：面对一个复杂系统，我们究竟应该怎么“拆”？
在系统架构设计中，其实可以从两个不同但相互关联的视角来看这个问题。
第一个视角是：
系统需要做什么（What should the system do?）
这个阶段暂时不考虑这些功能最终由哪些具体的硬件或者软件来实现，而是先识别系统需要完成哪些功能，以及这些功能之间存在怎样的行为、信息流和依赖关系。
通过这样的分析，我们可以逐步形成系统的 Functional / Logical Architecture。
第二个视角是：
系统最终由什么来实现（What is the system made of?）
也就是说，需要进一步确定系统由哪些 subsystem、component、hardware、software 等 system elements 构成，以及这些元素之间如何连接和交互，从而逐步形成 Physical Architecture。
在这两个视角下，书中涉及两种很典型的分解方式：Functional Breakdown Structure（FBS）和 Product Breakdown Structure（PBS）。
2. Functional Breakdown Structure：系统需要做什么？
FBS 关注的是系统“需要做什么”。
它从系统的高层功能出发，将功能逐层向下分解。功能分解本身并不等同于完整的 Logical Architecture，但它是建立 Functional / Logical Architecture 的一个重要基础。
比如对于智能眼镜，如果有一个高层需求是：
“系统应能够根据用户的位置和姿态实时显示导航信息。”
那么从功能角度，可以继续分解成：
获取用户位置
→ 获取用户姿态
→ 计算导航路径
→ 生成显示信息
→ 渲染图像
→ 向用户显示导航提示
如果继续往下分解，“获取用户姿态”还可以拆成：
采集传感器数据
→ 估计头部运动
→ 融合不同传感器信息
→ 输出用户姿态
在这一层，我们暂时不关心姿态最终是通过 IMU、Camera 还是其他传感器获得，也不关心图像最终由哪一颗 SoC 处理。
我们首先需要回答的是：
为了满足这个需求，系统必须具备哪些功能？这些功能之间又是什么关系？
随着功能、行为、信息流和逻辑接口逐渐被定义，就可以进一步形成系统的 Logical Architecture。
3. Product Breakdown Structure：系统最终由什么组成？
PBS 则更多关注系统“由什么组成”。
对于同一个智能眼镜系统，我们可能进一步将系统分解为：
Sensing Subsystem
Computing Subsystem
Display Subsystem
Power Subsystem
Communication Subsystem
然后继续向下分解。
例如：
Sensing Subsystem 中包含 Camera、IMU、Ambient Light Sensor；
Computing Subsystem 中包含 SoC、Memory、Storage；
Display Subsystem 中包含 Display Engine、Optical Module；
Power Subsystem 中包含 Battery、PMIC。
PBS 帮助我们描述系统物理组成的层级结构。
但是 PBS 本身也并不完全等同于 Physical Architecture。
一个完整的 Physical Architecture 除了描述“有哪些物理元素”，还需要定义这些元素之间的 interfaces、connections、data flow、power flow 以及 interaction。
所以我现在理解，FBS 和 PBS 真正有意思的地方，其实并不只是“两种不同的拆解方法”，而是它们背后所代表的两个不同架构视角，以及这两个视角之间如何建立映射。
4. 从 Logical Architecture 到 Physical Architecture：Allocation
一边是：
What should the system do?
另一边是：
What elements will realize those functions?
这中间就会涉及 Systems Engineering 中一个很重要的概念：Allocation。
例如，“姿态估计”这个功能可能并不是由一个单独的部件来实现，而是由 Camera、IMU、SoC 和 Sensor Fusion Software 共同完成。
反过来，一颗 SoC 也可能同时承担姿态计算、图像渲染、通信控制等多个功能。
因此，Functional / Logical Architecture 和 Physical Architecture 之间通常并不是简单的一一对应关系，而是可能存在：
一个 Function → 多个 Physical Elements
以及：
一个 Physical Element → 多个 Functions
Systems Engineer 需要做的，就是逐步建立这些 relationships 和 allocations，并确保 requirements、functions、logical elements 和 physical elements 之间保持清晰的 traceability。
这样我们才能回答一些非常基础但也非常重要的问题：
为什么系统里面需要这个 component？
它承担了哪些 functions？
这些 functions 又是在满足哪些 requirements？
反过来，每一条重要的 requirement 最终有没有被某一个 system element 实现？
后续又应该通过什么方式进行 verification？
从这个角度来看，系统工程并不是简单地“把一个复杂系统拆小”，而是要在不同层级、不同视角之间建立一套可追溯的关系。
并且，真实的系统开发并不是这样单向、线性地一路向下，而是一个不断迭代的过程。
Requirements 会影响 Architecture，Architecture Analysis 又可能反过来发现原来的 Requirements 不合理；
Physical Architecture 的约束可能迫使我们重新调整 Logical Architecture；
Verification 的结果也可能暴露前面的设计或者需求存在问题。
所以更准确地说，这些活动之间实际上是一个不断迭代、不断闭环的关系。
5. 系统方案并不唯一：Decision Making 和 Trade-off
在这个过程中，还会自然出现另外一个很典型的 Systems Engineering 问题：Decision Making。
因为一个功能通常不会只有一种实现方式。
还是以智能眼镜为例。
对于“姿态估计”这个功能，我们可能有：
方案 A：主要依赖 IMU；
方案 B：主要依赖 Camera；
方案 C：Camera + IMU Sensor Fusion。
对于显示系统，也可能存在不同的 optical architecture。
不同方案在 accuracy、latency、power consumption、weight、cost、thermal、reliability、manufacturability 等维度上可能各有优劣。
这个时候，Systems Engineer 要做的并不是简单地凭经验选择一个“看起来最好”的方案，而是建立 decision criteria，通过 trade study 对不同方案进行系统性比较。
比如：
更高的显示亮度，可能意味着更高的功耗；
更高的功耗，可能意味着需要更大的 Battery；
更大的 Battery，又可能进一步影响 Weight、Thermal 和 Ergonomics。
所以一个局部看起来更优的方案，放到整个系统里面，并不一定还是最优方案。
6. Local Optimum（局部最优） 和 System Optimum（全局最优）
不同专业领域工程师往往会从自己负责的领域出发，把某一个局部问题做到最好。
Optical Engineer 关注 optical performance；
Mechanical Engineer 关注 structure、weight 和 mechanical reliability；
Electrical Engineer 关注 circuit、power 和 signal integrity；
Software Engineer 关注 software architecture 和 implementation；
Algorithm Engineer 关注 accuracy、latency 和 computational complexity。
而 Systems Engineering 更需要回答的是：
当这些局部设计组合到一起以后，整个系统是不是仍然是一个合理的系统？
换句话说，各个专业可能更多关注的是：
Local Optimum
而 Systems Engineering 必须关注的是：
System Optimum
一个专业内部的最优方案，并不一定等于整个系统的最优方案。
7. Systems Engineer 的核心能力和专业边界
SE 的价值并不在于比 Optical Engineer 更懂光学，比 Mechanical Engineer 更懂结构，或者比 Software Engineer 更懂代码。
各个专业工程师在自己的领域中，都会拥有远远超过 SE 的专业深度。
SE 真正需要具备的，是从系统层面理解不同专业之间的 interfaces、dependencies、constraints 和 trade-offs，并确保不同局部设计最终能够组合成一个满足整体 stakeholder needs 的系统。
所以我现在会把 Systems Engineer 的职责理解成：
SE 不负责替代各个专业做设计，而是负责确保各个专业的设计最终能够组成一个满足系统目标的整体。
从这个角度来看，SE 所面对的专业对象很多时候并不是某一个具体的 component，而是 components 之间的关系。
比如：
一个光学方案的改变，会不会影响机械空间？
机械空间变化，会不会影响 Battery？
Battery 变化，会不会影响重量和 Thermal？
Thermal 又会不会限制 SoC performance？
SoC performance 降低以后，会不会影响算法 latency？
算法 latency 最后又会不会导致原来的 user experience requirement 无法满足？
这些跨 subsystem、跨 discipline 的 dependencies，恰恰是复杂系统中最容易出现问题的地方，也是 Systems Engineering 最需要发挥作用的地方。
8. 我目前对 Systems Engineering 的理解
因此，再去看 Requirements Management、Architecture Design、Interface Management、Decision Management、Risk Management、Integration、Verification 和 Validation，会发现这些原本看起来比较分散的活动，其实都在解决同一个问题：
如何把一个最初可能还比较模糊的 stakeholder need，逐步转化成一个可分析、可实现、可集成、可验证，并最终真正满足系统目标的复杂系统。
这也是我目前读《INCOSE Systems Engineering Handbook》一个比较大的收获。
以前可能会觉得 Systems Engineering 是很多流程、文档和方法的集合。
但现在越来越觉得，它真正想解决的其实是一个很本质的问题：
当系统复杂到任何一个人、任何一个专业都无法独立理解和优化全部问题的时候，我们应该用什么样的方法，仍然能够对这个系统进行有效的设计、决策、集成和验证。
附件：
- INCOSE Systems Engineering Handbook.pdf（8.7MB）
相关笔记
- 📁 返回本主题 MOC
- [书序——BMS电池管理系统从硬件到系统]]
- [很多人学不好电机的真正原因]]
- [轴向磁通电机产业革命：新能源汽车与机器人时代的行业方向]]
- [周报-嵌入式行业动态-8月]]
- [三分钟速览-MIPI-CSI接口]]
- [三分钟速览-MIPI-DSI接口]]
- [需求到功能的转化方法]]
- [系统工程-INCOSE手册解读]]
- [架构分层及其价值]]
- [架构教学：教原理而非抄Linux]]
- [perf火焰图+AI定位CPU瓶颈]]
- [工业级Debug思维体系与逻辑闭环]]
- [嵌入式系统架构设计哲学]]
- [问题模型二（SIM卡国外联网问题）]]
- [问题模型二续（SIM卡联网排查实践）]]
- [问题模型二续（SIM卡联网排查实践）]]